Everything about Aspect-oriented Programming totally explained
In software engineering, the programming paradigms of aspect-oriented programming (AOP), and aspect-oriented software development (AOSD) attempt to aid programmers in the separation of concerns, specifically cross-cutting concerns, as an advance in modularization. AOP does so using primarily language changes, while AOSD uses a combination of language, environment, and method.
Separation of concerns entails breaking down a program into distinct parts that overlap in functionality as little as possible. All programming methodologies—including procedural programming and object-oriented programming—support some separation and encapsulation of concerns (or any area of interest or focus) into single entities. For example, procedures, packages, classes, and methods all help programmers encapsulate concerns into single entities. But some concerns defy these forms of encapsulation. Software engineers call these crosscutting concerns, because they "cut" across multiple modules in a program.
Logging offers one example of a crosscutting concern, because a logging strategy necessarily affects every single logged part of the system. Logging thereby crosscuts all logged classes and methods.
Gregor Kiczales and his team at Xerox PARC originated the concept of AOP. This team also developed the first and most popular general-purpose AOP language, AspectJ. IBM's research team emphasized the continuity of the practice of modularizing concerns with past programming practice, and offered the more powerful (but less usable) HyperJ and Concern Manipulation Environment, which have not seen wide usage. The examples in this article use AspectJ, as it's the most widely known.
Any AOP language has some crosscutting expressions that encapsulate the concern in one place. The difference between AOP languages lies in the power, safety, and usability of the constructs provided. For example, interceptors that specify the methods to intercept express a limited form of crosscutting, without much support for type-safety or debugging. AspectJ has a number of such expressions and encapsulates them in a special class, an aspect. For example, an aspect can alter the behavior of the base code (the non-aspect part of a program) by applying advice (additional behavior) at various join points (points in a program) specified in a quantification or query called a pointcut (that detects whether a given join point matches). An aspect can also make binary-compatible structural changes to other classes, like adding members or parents.
Many AOP languages support method executions and field references as join points. In them the developer can write a pointcut to match, for example, all field-set operations on specific fields, and code to run when the field is actually set. Some also support things like defining a method in an aspect on another class. AOP languages can be compared based on the join points they expose, the language they use to specify the join points, the operations permitted at the join points, and the structural enhancements that can be expressed.
Motivation and basic concepts
Some code is scattered or tangled, making it harder to understand and maintain. It is scattered when one concern (like logging) is spread over a number of modules (for example, classes and methods). That means to change logging can require modifying all affected modules. Modules end up tangled with multiple concerns (for example, account processing, logging, and security). That means changing one module entails understanding all the tangled concerns.
For example, consider a banking application with a conceptually very simple method for transferring an amount from one account to another:
void transfer(Account fromAccount, Account toAccount, int amount)
» This code snippet adds the acceptVisitor method to the Point class.
It is a requirement that any structural additions be compatible with the original class, so that clients of the existing class continue to operate, unless the AOP implementation can expect to control all clients at all times.
Implementation
There are two different ways AOP programs can affect other programs, depending on the underlying languages and environments: (1) a combined program is produced, valid in the original language and indistinguishable from an ordinary program to the ultimate interpreter; and (2) the ultimate interpreter or environment is updated to understand and implement AOP features. The difficulty of changing environments means most implementations produce compatible combination programs through a process that has come to be known as weaving. The same AOP language can be implemented through a variety of weaving techniques, so the semantics of a language should never be understood in terms of the weaving implementation. Only the speed of an implementation and its ease of deployment are affected by which method of combination is used.
Source-level weaving can be implemented using preprocessors (as C++ was implemented originally in CFront) that require access to program source files. However, Java's well-defined binary form enables bytecode weavers to work with any Java program in .class-file form. Bytecode weavers can be deployed during the build process or, if the weave model is per-class, during class loading. AspectJ started with source-level weaving in 2001, delivered a per-class bytecode weaver in 2002, and offered advanced load-time support after the integration of AspectWerkz in 2005.
Any solution that combines programs at runtime has to provide views that segregate them properly to maintain the programmer's segregated model. Java's bytecode support for multiple source files enables any debugger to step through a properly woven .class file in a source editor. However, some third-party decompilers are unable to process woven code because they expect code produced by Javac rather than all supported bytecode forms (see also "Problems", below).
Another alternative is deploy-time weaving(External Link). This basically implies post-processing, but rather than patching the generated code, this weaving approach subclasses existing classes so that the modifications are introduced by method-overriding. The existing classes remain untouched, even at runtime, and all existing tools (debuggers, profilers, etc.) can be used during development. A similar approach has already proven itself in the implementation of many Java EE application servers, such as IBM's WebSphere.
Terminology
The following are some standard terminology used in Aspect-oriented programming:
Cross-cutting concerns: Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.
Advice: This is the additional code that you want to apply to your existing model. In our example, this is the logging code that we want to apply whenever the thread enters or exits a method.
Point-cut: This is the term given to the point of execution in the application at which cross-cutting concern needs to be applied. In our example, a point-cut is reached when the thread enters a method, and another point-cut is reached when the thread exits the method.
Aspect: The combination of the point-cut and the advice is termed an aspect. In the example below, we add a logging aspect to our application by defining a point-cut and giving the correct advice.
Comparison to other programming paradigms
Aspects emerged out of object-oriented programming and computational reflection. AOP languages have functionality similar to, but more restricted than metaobject protocols. Aspects relate closely to programming concepts like subjects, mixins, and delegation. Other ways to use aspect-oriented programming paradigms include Composition Filters and the hyperslices approach. Since at least the 1970s, developers have been using forms of interception and dispatch-patching that are similar to some of the implementation techniques for AOP, but these never had the semantics that the crosscutting specifications were written in one place.
Designers have considered alternative ways to achieve separation of code, such as C#'s partial types, but such approaches lack a quantification mechanism that allows reaching several join points of the code with one declarative statement.
Adoption risks
As with all immature technologies, widespread adoption of AOP is hindered by a lack of tool support, and widespread education. Some argue that slowing down is appropriate due to AOP's inherent ability to create unpredictable and widespread errors in a system. Implementation issues of some AOP languages mean that something as simple as renaming a function can lead to an aspect no longer being applied leading to negative side effects.
Programmers need to be able to read code and understand what's happening in order to prevent errors1. While they've grown accustomed to ignoring the details of method dispatch or container-supplied behaviors, many are uncomfortable with the idea that an aspect can be injected later adding behavior to their code. There are also valid security questions that code weaving raises.
Some programmers therefore object to all forms of bytecode weaving. AOP implementations are a particular concern for them because of its prevalence. One response in Java is to sign and seal the .jar files and prevent environments from deploying weaving class loaders affecting their code, but in some cases the deployment environment isn't under their control.
Even with proper education, understanding crosscutting concerns can be difficult without proper support for visualizing both static structure and the dynamic flow of a program. Visualizing crosscutting concerns is just beginning to be supported in IDEs, as is support for aspect code assist and refactoring.
Given the power of AOP, if a programmer makes a logical mistake in expressing crosscutting, it can lead to widespread program failure. Conversely, another programmer may change the join points in a program -- for example, by renaming or moving methods -- in ways that were not anticipated by the aspect writer, with unintended consequences. One advantage of modularizing crosscutting concerns is enabling one programmer to affect the entire system easily; as a result, such problems present as a conflict over responsibility between two or more developers for a given failure. Open questions of legal liability in such cases may also influence some to reject bytecode weaving altogether. However, the solution for these problems can be much easier in the presence of AOP, since only the aspect need be changed, whereas the corresponding problems without AOP can be quite difficult to fix.
Bytecode decompilation and weaving has grown as an implementation method for many approaches including model-based programming. Early implementations of that technology can address only the subset of Java bytecode produced by Javac, the standard compiler, and thus fail when encountering valid bytecode produced by weavers that would never be produced by Javac. These problems can take some time to sort out since there are few developers familiar with bytecode internals. In the meantime, programming teams might have to choose between two incompatible development technologies.
Using AOP judiciously to develop your own code can result in powerful succinct expressiveness. Using AOP to add to code written by someone else (especially when you don't have the source code) is risky. Since the risk is to code written by others, code weaving can be emotional for the authors of the original code. There is little moral grounding to guide programmers in these matters because morality isn't something often applied to coding practices. Until these matters are sorted out, widespread adoption of AOP is itself at risk.
Usage of supporting methodologies such as Test-driven development or Test automation can reduce some of the risks associated with employing AOP. Assurance that the aspect doesn't negatively impact the original author's intent can be verified through running tests. Employing AOP without such a safety net is frightening to many programmers, especially those who are not familiar with the methodologies employed by responsible practitioners of AOP.
The potential of AOP for creating Malware should also be considered. If security is a cross cutting concern implemented through the application of AOP techniques, then it's equally possible that breaking security can be implemented through injecting additional code at an appropriate place. For example, consider the impact of injecting code to return true at the beginning of a password verification function that returns a boolean value. This means that all programmers using languages that can be subjected to AOP techniques need to be aware of the potential of AOP to compromise their systems.
Do you know how hard it is to get a link from a large encyclopaedia? Well we're different and will prove it. To get a link from us just add the following HTML to your site on a relevant page:
Then simply click through this link from your web page. Our crawlers will verify your link, extract the title of your web page and instantly add a link back to it. If you like you can remove the words Totally Explained and embed the link in article text.
As long as your link remains in place, we'll keep our link to you right here. Please play fair - our crawlers are watching. Your site must be closely related to this one's topic. Any kind of spamming, dubious practises or removing the link will result in your link from us being dropped and, potentially, your whole site being banned.
)